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-.rfOD AND APPARATUS l-Cii ENFORCING SC--TV/AR!-. LICENSES 

Abstract 

The present invention comprises a method and apparatus for enforcing software licenses for resource libraries such as an apjnicatioii 
program^ £ (AK),a toolkit, a framework, a nintbne library, a dynamic link library (DLL), an applet ^^J^ 
or any other reusable resource. The present invention allows the resource library to be selectively used ^&on^d user software 

programs. The present invention can be used to enforce a "per-program" licensing scheme for a resource library whereby toe resource 
EteSyfc licensed only for use with particular software programs. In one embodiment, a license text string and a corresponding license 
LeTSe emotSdS m a" program that has been licensed to use a resource library. The license text stnng and ^the 

for example, by a resource library vendor to a program developer who wants to use the resource ^^^^^^^^L^f^ f^^to usl 
developed. The license text string includes information about die terms of the icense under which the ^™*P™&™ JJKaSS 
the resource library. The license key is used to authenticate the license text string. The resource library in turn is provided with means for 
reL'n?thriicStext string and L license key, and for determining, using the license key. whether the license text stnng is auAenUc 
Swnether StoS* text string has been altered. Resource library functions are made available only to a program having an authentic 
and unaltered license text string. 
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METHOD AND APPARATUS FOR ENFORCING SOFTWARE LICENSES 

BACKGROUND OF THE INVENTION 

5 1. FIELD OF THE INVENTION 

The present invention relates generally to the distribution of computer 
software, and more particularly to a method and apparatus for automated 
enforcement of computer software licenses. 

10 

2. BACKGROUND ART 

Some computer software programs use so-called "resource libraries" to 
provide ..>«rt of *heir functionality. There «s usually a licer-ae fee required io 
15 use a resource library. Under current schemes, it is not always possible to 
charge the license fee to all users of a resource library. This problem can be 
understood by comparing software structures that use resource libraries with 
basic software structures that do not. 

20 Basic Software Structure 

Figure 1 illustrates a basic software structure. In the example of Figure 
1, the software comprises two layers. These layers are the operating system 
110, and the application program 120. Operating system 110 is responsible for 
25 controlling the allocation and usage of hardware resources such as memory, 
central processing unit (CPU) time, disk space, and peripheral devices. 
Operating system 110 provides a variety of specific functions that can be 
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utilized by a variety of software programs such as application program 120. 
Application program 120 provides specific end user functions, such as word 
processing, database management, and others. Application program 120 
communicates with the computer hardware via functions provided by 
5 operating system 110. Operating system 110 provides an interface between 
hardware 100 and application program 120. 

Resource Libra Hps 

Figure 2 illustrates a second software structure. The software structure 
of Figure 2 contains an additional layer of software, resource library 215, 
interposed between application program 220 and operating system 110. 
Resource library 215 provides a pre-packaged set of resources or routines that 
can ve acnv ??! V/ <r\-fhv p£Cft?-i\-$ si-:h as application pi ax..- 120 u ..' r 
executic.i. ' ' .go .or-/--, • provide higner level iu-k lions than i-b^=a 
provided by operating system 210. For example, these resources may provide 
routines for managing a graphical user interface, for communicating with 
other computers via a network, or for passing messages between program 
objects. Typically, resource library 215 provides one or more resources or 
functions that can be used by many different software programs. By using the 
pre-packaged resources provided by resource library 215, a software program 
such as application program 220 can be made smaller and program 
development time can be shortened because the program itself need not 
include code to provide the functions provided by resource library 215. 
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In addition to application programs, resource libraries are used by other 
types of software programs, including device drivers, utility programs and 
other resource libraries. 

Resource library 215 constitutes any set of one or more resources that 
exists separately from an application program or other software program and 
that can be used by more than one software program. For example, resource 
library 215 may comprise an application program interface (API), a toolkit, a 
framework, a resource library, a dynamic link library (DLL), an applet, or any 
other reusable resource, including an application program that can be accessed 
by another program (e.g. by using object linking and embedding (OLE)). 
Examples of resource libraries include Windows DLL's (DLL's used with the 
Microsoft Windows (TM) operating environment), the Apple Macintosh (TM) 
toolkit, Lhe OpanStep API from NeXT Software, Inc., OLE -aabled application 
programs such ejs Microsoft Word (TM), Java packages, and ActiveX applets. 

A software program typically utilizes a resource provided by a resource 
library by sending an appropriate message to the resource library and 
supplying the parameters required for the resource to be executed. Assuming 
the appropriate parameters have been supplied, the resource executes, and an 
appropriate response message is returned to the requesting program. 

A software program may use resources provided by several different 
resource libraries, a resource library may be used by several different programs, 
and a resource library may itself use other resource libraries. Figure 3 
illustrates a computer system that includes several programs and several 
resource libraries. In the example of Figure 3, there are two application 
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programs 300 and 310, and three resource libraries 320, 330, and 340. 
Application program 300 uses resources provided by operating system 110 and 
by resource libraries 320 and 330. Application program 310 uses resources 
provided by operating system 110 and by resource libraries 330 and 340. The 
5 resources of resource library 330 are thus shared by application programs 300 
and 310. 

License Fee 

10 Generally, computer software is licensed to an end user for a fee. The 

end user pays a single purchase price or license fee in exchange for the right to 
use the end user program on a computer system. Resource libraries are often 
packaged or "bundled" with an end user program by the maker of the program 

si- h !•-.- • : f»r.d v rec ■■ copy . >f re*o; uro .'tf..r-mt> . tXj.sii-C'i by a 

15 progi a;. . ten the end uzjt buys a of li .r ;•■ • - • u . The price of the 
resource library is built into the end user progiau.i ^rice. The end user 
program developer, in turn, pays a royalty to the resource library vendor for 
the right to bundle and resell the resource library. 

20 Since a resource library can be used with multiple end user programs, 

once the end user receives a copy of the resource library, the end user can use 
the resource library with any other program that is compatible with the 
resource library. In this case, the resource library vendor receives no 
additional revenue when the vendor's resource library is used with additional 
25 programs. Accordingly, it would be desirable for a resource library vendor to 
be able to ensure that an end user can use the resource library only with 
programs for which a license fee has been paid to the vendor for use of the 
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resource library. Thus there is a need for a software mechanism for enforcing 
software license agreements that automatically ensures that a resource library 
can only be used by programs that have been licensed for use with the 
resource library by the resource library vendor. 
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SUMMARY OF THP. TMWMTTONy 



The present invention comprises a method and apparatus for enforcing 
software licenses for resource libraries. The term "resource library" as used 
5 herein refers to any reusable software resource that is usable by more than one 
program or other resource library. The term "resource library" includes, but is 
not limited to, an application program interface (API), a toolkit, a framework, 
a runtime library, a dynamic link library (DLL), an applet (e.g. a Java or 
ActiveX applet), an application program whose functionality can be accessed 

10 by other programs (e.g. using OLE) or any other reusable resource. The present 
invention allows the resource library to be selectively used only by authorized 
end user software programs. The present invention can be used to enforce a 
"per-program" licensing scheme for a resource library whereby the resource 
Iibx,. -v is He-.'.- d :.nly ,V,. i.se ~}>h p.:- 'kninr rzliwar- pv.-.^rw • , v,.- : .i 

15 site licenses and other licensi;.^ schemes. 



In one embodiment, an access authorization indicator such as a license 
text string and a corresponding license key are embedded in a program that 
has been licensed to use a resource library. The license text string and the 
20 license key are supplied, for example, by a resource library vendor to a 

program developer who wants to use the resource library with an end user 
program being developed. 

The license text string includes information about the terms of the 
25 license under which the end user program is allowed to use the resource 

library. In one embodiment, the license key is an algorithmic derivation, such 
as, for example, a digital signature, of the license text string that is used to 
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authenticate the license text string. The resource library in turn is provided 
with a checking routine that includes means for reading the license text string 
and the license key, and for determining, using the license key, whether the 
license text string is authentic and whether the license text string has been 
5 altered. Resource library functions are made available only to a program 
having an authentic and unaltered license text string. 

In one embodiment, the license key constitutes the resource library 
vendor's digital signature of the license text string. The resource library has a 
10 checking routing for verifying the resource library vendor's digital signature. 
The resource library is unlocked and made available for use with the 
requesting program only if the license text string is verified as authentic by the 
" resource library. For a given program, only the resource library proprietor can 
- produce * license key for a particular licence agre^m^nt thai will unlock the 
"L'i resource library for thai program and tnat program only. Any modification oi 
the license key or the license agreement text string in the requesting software 
program is detected by the checking routine, causing the resource library to*, 
remain locked. The license text string may also specify an expiration date for 
the license, in which case the resource library is unlocked only if the 
20 expiration date has not yet occurred. 

In one embodiment, a per-site enforcement method is provided, in 
which any software program present at a given user site works with the 
resource library once the resource library is provided with the proper per-site 
25 license key. 
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BRIEF DESCRIPTION OF THF 

Figure 1 illustrates an example of a software structure. 

5 Figure 2 illustrates an example of a software structure including a 

resource library. 

Figure 3 illustrates an example of a software structure including several 
application programs and resource libraries. 

10 

Figure 4 illustrates an embodiment of a computer system that can be 
used with the present invention. 

:<'i<r,j-.-o •? MiuM.-ateo -t son w.-> ce s'.r-i iu;- 1 of: oor- -,i,hai'' .^rui • .? vh« 
15 preoc.u invention. 

Figure 6 illustrates a software structure of one embodiment of the 
present invention. 

20 Figure 7 is a flow chart illustrating the operation of one embodiment of 

the present invention. 

Figure 8 illustrates a software structure of one embodiment of the 
present invention. 

25 

Figure 9 illustrates a software structure of one embodiment of the 
present invention. 
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Figure 10 is a flow start illustrating the operation of one embodiment of 
the present invention. 

5 Figure 11 is a flow start illustrating the operation of one embodiment of 

the present invention. 

Figure 12 is a flow start illustrating the operation of one embodiment of 
the present invention. 

10 

Figure 13 illustrates a software structure of an embodiment of the 
present invention using the OpenStep API. 

I'igure 14 iiluciraies ua embodiment of the invention in which the 
15 resource library is an applet. 
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DETAILED DESCRIPTION OF THF TMT/T? mtthm 

A method and apparatus for enforcing software licenses is described. In 
the following description, numerous specific details are set forth in order to 
5 provide a more thorough description of the present invention. It will be 

apparent, however, to one skilled in the art, that the present invention may be 
practiced without these specific details. In other instances, well-known 
features have not been described in detail so as not to obscure the invention. 

10 Computer System 

The present invention can be implemented on any of a variety of 

computer systems, including, without limitation, network computers, special 

15 Purpose com p :.ustrated in Hgure 4. coi^air, .m shown in 
Figure 4 includes a CPU unit 400 that includes a central processor, main 
memory, peripheral interfaces, input-output devices, power supply, and 
associated circuitry and devices; a display device 410 which may be a cathode 
ray tube display, LCD display, gas-plasma display, or any other computer 
display; an input device 430, which may include a keyboard, mouse, digitizer, 
or other input device; non-volatile storage 420, which may include magnetic, 
re-writable optical, or other mass storage devices; a transportable media drive 
425, which may include magnetic, re-writable optical, or other removable, 
transportable media, and a printer 450. The computer system may also 
25 include a network interface 440, which may include a modem, allowing the 
computer system to communicate with other systems over a communications 
network such as the Internet. Any of a variety of other configurations of 



20 
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computer systems may also be used. In one embodiment, Jhe computer 
system comprises an Intel Pentium (tm) CPU and runs the Microsoft 
Windows 95 (tm) operating environment. In another embodiment, the 
computer system comprises a Motorola 680X0 series CPU and runs the 
5 NeXTStep operating system. 

When a computer system executes the processes and process flows 
described herein, it is a means for enforcing software licenses. 

10 The invention can be implemented in computer program code in any 

desired computer programming language. 

Licensin g Mod ule 

15 Figure 5 is a block diagram illustrating software components of one 

embodiment of the present invention. As shown in Figure 5, this 
embodiment, like the prior art embodiment of Figure 2, includes computer 
hardware 100, operating system 110, application program 220 and resource 
library 215. However, the present invention adds two additional components: 

20 Program licensing module 500 and resource library licensing module 510. 
These modules are shown in greater detail in Figure 6. 

Figure 6 illustrates program licensing module 500 and resource library 
licensing module 510 in one embodiment of the present invention. As 
25 shown in Figure 6, program licensing module 500 contains license text string 
600 and license key 610. License text string 600 contains data specifying terms 
of the software license agreement under which the resource library vendor 
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10 



15 



has licensed the program containing program licensing module 510 to use the 
vendor's resource library. For example, license text string 600 may include the 
following text: 

Table 1: Fran ce LicensP Text String 

ii^ n =!S y f i9ht 1997 • Resource library Vendor. Inc. Program A is 
licensed to use Resource Library D . No expiration date. This 
Ixcense may not be legally copied or transferred to another 
program. " 

In the example shown in Table 1, license text string 600 specifies the name of 
the resource library vendor ("Resource Library Vendor, Inc.), the name of the 
program licensed to use the resource library ("Program A"), and the name of 
the resource library that has been licensed ("Resource Library D"). License text 
string 600 also indicates that the license has "No expiration date." 



m one embodiment, license ko/ 610 comprises a digital signature of the 
20 resource library vendor. 



A digital signature is a mechanism that has been developed to help 
ensure the integrity of electronic messages. A digital signature is used to 
authenticate an electronic message and to determine whether an electronic 
25 message has been altered. 

One form of digital signature uses a message digest. A message digest is 
a value that is generated when an electronic message is passed through a one 
way encryption process ("digesting process") such as a hashing routine. An 
30 ideal digesting process is one for which the probability that two different 

electronic messages will generate the same message digest is near zero. In this 
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form of digital signature, both the originator and the recipient need to know 
which digesting process is being used. The originator generates the electronic 
message, and generates a message digest by passing the electronic message 
through the digesting process. The originator digitally signs the resulting 
5 message digest, for example by performing an algorithmic operation on the 
message digest using the originator's private key. Alternatively, instead of 
generating a message digest and signing the message digest, a sender may sign 
the message itself. 

10 To verify the authenticity of a digitally signed message, the recipient 

obtains the electronic message and the digital signature of the sender. The 
recipient verifies the digital signature using an appropriate verification 

process. For example, in one embodiment, the recipient verifies the digital 
::.ign?tu.e by r- nfoxinir.-y an algorithmic process d> the digital signature usirg 
15 the sender's public key. The verification process .^rifies that tuo electronic 
message was (1) digitally signed by the sender, and (2) that the electronic 
message content was not changed from the time that it was signed to the time 
that the digital signature was verified. 

20 In the present embodiment of the invention, the "message" that is 

digitally signed is license text string 600. The signer is the resource library 
vendor. The result is license key 610. 

License text string 600 and license key 610 are used by resource library 
25 licensing module 510 to verify that a requesting program has been licensed to 
use the resource library. As shown in Figure 6, resource library licensing 
module 510 includes a license verification module 620. When a program 
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requests access to the resource library, resource library licensing module 510 
reads license text string 600 and license key 610 from the requesting program. 
In one embodiment, license text string 600 and license key 610 are sent to the 
resource library by the requesting program along with a request for access to 
the resource library. In another embodiment, resource library licensing 
module 510 reads license text string 600 and license key 610 from a constant 
definition section of the requesting program. 

Resource library licensing module 510 uses license key 610 to verify the 
content of license text string 600 in the same manner as a digital signature is 
used to verify an electronic message. Using license verification module 620, 
resource library licensing module 510 verifies that license text string 600 is 
authentic (i.e. was generated by the resource library vendor) and unaltered. If 
v .<fxOi.:-ii. £.•<;: _*S3 L ii.^uo rr.rd'A, J'!iiic?MMi<r th"i ilia *'Jtal r unatvr.j is 
iV - : - "•" '• i/ resouivo .library - , lvJ dule ULv refuses the ic questing 
program's request for access to thu resource library. If the verification process 
is successful, resource library licensing module 510 inspects the license to 
determine any license limitations included in license text string 600. 

The example license text string 600 shown in Table 1 above identifies 
"Program A" as the program that is licensed to use the resource library, and 
states that the license has "No expiration date." Resource library licensing 
module 510 obtains the name of "Program A" from license text string 600, and 
checks whether the requesting program is Program A. If the requesting 
program is a program other than Program A, access to the resource library is 
denied. 
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Rather than specifying "No expiration date" as in the present example, 
license text string 600 may specify an expiration date and /or a beginning date 
for the license. If any such dates are specified in license text string 600, 
resource library licensing module 510 checks to make sure that the current 
5 date falls within the period of validity of the license prior to granting access to 
the resource library. If the current date is not within the license's period of 
validity, the requesting program is denied access to the resource library. 

Access Procedure 

10 

The process used by a resource library to grant or deny access to a 
requesting program in one embodiment of the invention is illustrated in 

Figure 7. In one embodiment, this process occurs the first time a program 
requests access :o a resource libra iy. In another embodiment, this process 
15 occurs each time the resource library receives a request for access. 

As shown in Figure 7, the process begins with a requesting program 
making a request to use the resource library at step 700. At step 705, the 
resource library obtains the requesting program's license text and license key. 
20 The license text and license key may, for example, be included in the request, 
or the resource library may read the license text and license key from a 
constant declaration area of the requesting program, or the resource library 
may obtain the license text and license key by some other means. 

25 After obtaining the license text and license key, the resource library 

verifies the authenticity of the license text, using the license key, at step 710. 
At step 725, a the resource library determines whether the verification is 
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successful. If the authenticity of the license text is not verified, access to the 
resource library is denied at step 730. 

If the verification of the authenticity of the license text is successful, the 
5 resource library checks the license terms included in the license text at step 
735. At step 740, the resource library determines whether a limited validity 
period is specified in the license text. If no validity period is specified, the 
process continues on to step 755. If a validity period is specified, the resource 
library checks whether the validity period has expired at step 745. The validity 
10 period will have expired either if the current date is before a beginning date 
specified in the license text or if the current date is after an expiration date 
specified in the license text. If the validity period has expired, access to the 
resource library is denied at step 750. 

1 - 1 if the .'-.-ikliiy per.' *- Las not expi.i pi.;,. . \, dimes to step /So. 

At step 755, the resource library determines whether l'r.2 requesting program is 
the same program as the program specified in the license text. If the 
requesting program is not the program specified in the license text, access to 
the resource library is denied at step 760. If the requesting program is the 

20 program specified in the license text, the resource library checks whether there 
are any other license terms contained in the license text at step 765. If there are 
no other license terms, access to the resource library is granted at step 770. If 
there are other license terms, the resource library checks whether those terms 
are satisfied at step 775. If the terms are not satisfied, access to the resource 

25 library is denied at step 780. If the terms are satisfied, access to the resource 
library is granted at step 785. 
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The invention may be implemented in the Objective-C language. 
Objective-C is essentially the ANSI C language with object messaging 
extensions. A full description of the Objective-C language appears in "Object- 
Oriented Programming and the Objective-C Language," published by Addison- 
5 Wesley (ISBN 0-201-63251-9) (1993), and incorporated by reference herein. 
However, the invention can also be implemented in any other suitable 
computer programming language. 

As described below, the invention can be implemented by embedding 
10 appropriate segments of program code in the source code of a program that 

uses a resource library and in the source code of the resource library itself. The 
resource library is compiled to produce an executable implementation which 

can be linked to a compiled and executable version of the program. 

15 judic ation Program Interface ( API ) 

In one embodiment of the invention, the resource library is an 
application program interface ("API"). An API has three major functions: it 
receives requests from an application program to carry out fundamental 
20 operations such as receiving user input or displaying output; it converts each 
request into a form understandable by the particular operating system then in 
use; and it receives responses and results from the operating system, formats 
them in a uniform way, and returns them to the application program. 

25 APIs generally are prepared in an executable implementation which is 

compiled specifically for the underlying operating system. This is necessary 
because different operating systems provide different calling mechanisms and 
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communications methods for such primitive operations as reading and 
writing a mass storage device. For example, an API may provide a "draw(x / y) M 
function that can be called by an application program to draw a point at 
coordinates (x,y) on the display device of a computer system. Upon receipt of a 
draw(x,y) request from an application program, the API converts the request 
into a command or function call specific to the operating system then in use. 
For example, the API might convert the draw(x,y) request into a series of 
machine instructions to load registers with the x,y values and call an 
operating system function or generate an interrupt. The person writing the 
application program need not worry about such details. 

In some cases the API refers to or calls functions located in an external 
function library such as a set of device drivers rather than directly calling the 

opcj:»*:.-»K ay.h;m. -'".ivicr. .iriv- ■; arc .^ruul t;;. - -tab." prog. - .-j p : • ^nabh 
Lhe opera tin- system to address and work with pmi:.- J ... hardware devices 
such as video adapters and printers. Device drivers also constitute a form of 
resource library. 

Depending on the operating system, the API can be prepared in any of 
several executable formats such as a runtime library, device linked library 
(DLL), or other executable file. The API is provided to the end user in one of 
these object code versions, or "implementations," of the API. In industry 
usage the term API can refer to a definition or specification of functions in the 
API, to the source code of the API that implements such functions, or to the 
executable version of such source code which is ultimately distributed to and 
used by end users. Examples of APIs are the OpenStep API, available from 
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NeXT Software, Inc., Redwood City, California, and the Visual Basic DLL 
available from Microsoft Corporation, Redmond, Washington. 

The term API as used herein also includes the Java programming 
5 language. Rather than being distributed in executable form, Java programs are 
distributed as packages of 'bytecodes." The bytecodes are compiled at runtime 
into executable code by a Java Virtual Machine (JVM) resident on the 
computer on which the Java program is run. Different JVM's are used for 
different computer processors and operating systems. However, all JVM's 
10 read the same bytecode. Accordingly, Java bytecode programs and packages are 
platform independent. Java bytecode programs and packages need only be 
written in one form. The JVM's take care of adapting the bytecode to different 
computer platforms. Packages of Java bytecode can be used by different Java 
programs, ci-A, us such, const? resource libraries. 

; 15 

Generally the end user can buy the executable version of the API 
implementation separately from any particular application program from its 
creator or vendor, or the end user may buy the API implementation bundled 
with an application program that requires and uses the API to run. 

20 

In either case, the API implementation is installed in executable form 
in the end user's computer system (typically by copying it to a mass storage 
device such as a hard disk). After the API implementation is installed, the 
end user can launch (begin running) an application program which uses the 
25 API implementation. The application program locates the API 

implementation on the hard disk and references, calls, or is linked to the API 
implementation. In operation, when the application program needs to carry 
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out an operation implemented in the API implementation, such as drawing a 
line on the screen, the application program calls the appropriate function in 
the API implementation. The appropriate function in turn tells the operating 
system (or the device independent windowing extensions, or another device 
5 driver) how to execute the desired operation. 

A significant advantage of the use of APIs is that an application 
program, such as a word processor, can be written to communicate only with 
the API, and not with the operating system. Such an application program can 

10 be moved or ported to a different operating system without modifying the 
program source code. Because of this, application programs written for APIs 
are said to be operating system independent, meaning that the application 
program source code can be moved without modification to another 
r<y-'.put.?r jjys+r-.-a !->av:.;£ a rK f fcront «?pi 3 syst*": \ t ?.rd recc^piV--- ~ A 

16 •••V.ed vv ;:: > -''PI iuiplcrn.N." t iion prepared for thai < .•e/aiing c} s--: /'i in- 
ability to move unmodified application source code to different operating 
systems is a key advantage of using APIs. 

However, from the point of view of API vendors, APIs also have the 
20 significant disadvantage that an end user needs only one copy of the API to 
run multiple application programs which are compatible with the API. Since 
the API provides generic input, output, and processing functions, it will work 
with a variety of different end user application programs. Some software 
vendors desire to restrict use of their API implementations to one application, 
25 or to require the end user to purchase a key to the API for each application 
acquired by the end user, so that the end user pays a different or larger fee to 
use additional application programs. 
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The present invention provides a way to arrange a resource library such 
as an API to work only with particular authorized application or other end 
user programs. 

5 

API License Embodiment 

As is well known in the art, the source code of a computer program can 
be divided into several components including a variables declaration area, a 

10 constant declaration area, and a procedure definition area. Figure 9 illustrates 
an embodiment of the present invention that is used with an API. As shown 
in Figure 9, in this embodiment, an application program 900 is provided with 
a LicenseKeyString constant 902 and a Li cense AgreementString constant 904 
in ihe cr-nfcian! df-lu; aliens a^a 901 the applies -on program's souro; ~r>d&. 

15 hi ihe embodiment of Figure 9, LicenseKeyString 902 and 

LicenseAgreementString 904 are declared as global string constants. 

In one embodiment, LicenseAgreementString 904 contains a text string, 
prepared by the vendor of the API, that describes in human readable text the 
20 license restrictions concerning use of the API applicable to the application 
program. For example, the LicenseAgreementString may read, "This API is 
licensed for individual internal use only for concurrent use only with Word 
Processor application program." The specific text of the 

LicenseAgreementString is prepared by the licensor of the API. The text can be 
25 any arbitrary combination of words, symbols, or numbers. 
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The LicenseKeyString 904 contains a key corresponding to and based 
upon the LicenseAgreementString 902. For example, the LicenseKeyString 
can be a digital signature of the LicenseAgreementString prepared by 
providing the LicenseAgreementString and a private key of the API vendor to 
a digital signature process. The precise method of generating the 
LicenseKeyString is not critical, provided that only the licensor of the API can 
generate a unique LicenseKeyString corresponding to the 
LicenseAgreementString. The values of the two strings are created by the 
vendor of the API and are provided to the person or company that is 
developing the end user application program (for example, the API vendor 
can send the two string values to the application program developer by e- 
mail). The application program developer is instructed by the API vendor to 
place the string declarations in the source code of the developer's end user 

.lovcJop. ,• .• r, : not • ■.' , valuer. r,- C i or hi. : , ■ • ..-.-..» users of Mie eno 
user application program. The two strings are compiled into the executable 
form (or, in the case of Java, the bytecode packages) of the application program. 
This binds the LicenseKeyString and LicenseAgreementString into the 
executable code (or bytecode) of the application program. 

As further shown in Figure 9, API 920 is provided with an UNLOCK 
function 923 and a CHECK LICENSE function 921 for testing whether the 
LicenseKeyString matches the LicenseAgreementString. In the embodiment 
of Figure 9, the CHECK LICENSE function 921 includes sub-function CHECK 



25 922. 
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APT Procedure 



Figure 10 is a flow diagram of processing steps of the UNLOCK function 
923. The process of Figure 10 may, for example, be carried out at runtime, 
5 when both the application program and the API are compiled, linked, and 
running. 

The UNLOCK function is called by the API upon initialization of the 
API, for example, upon being called by application program 900 or by some 

10 other calling function, object, or program (the "calling entity"). Processing 

begins at step 1002. The UNLOCK function first checks to see whether the API 
has been provided with a site license that allows the API to be used with any 
calling entity on the computer in which the API has been installed. In this 
e> abodi-uent, a oite license is indicate.-: by add : ng a*i appropiiatf* 

15 LicenseKeyString and LicenseAgreementS-ri'-g to the API when the is 
installed. This process is described in greater detail below. An appropriate 
LicenseAgreementString may, for example, be "API site license granted. This 
API may be used with any application program at the site at which it is 
installed." The corresponding appropriate LicenseKeyString may, for 

20 example, be derived by applying the API vendor's private key and a digital 
signature process to the LicenseAgreementString. 



The process of checking for a site license begins at step 1004 where the 
UNLOCK function locates and extracts (to the extent they have been provided 
25 to the API) a LicenseKeyString and a LicenseAgreementString from within the 
API. Control is then passed to step 1006 where the function tests whether the 
API is licensed under a site license for unrestricted use with any application 



WO 99/05600 



PCT/TJS98/15340 



24 



10 



program. The test of step 1006 is accomphshed by verifying ^ au[h Qf 
the LicenseKeyString and LicenseAgreementString extracted from the API 

and, if authentic, determining whether the LicenseAgreementString indicates 

that a site license has been granted. 

The authenticity of the LicenseAgreementString and LicenseKeyString 
,s determined by passing the LicenseAgreementString, the UcenseKeyString 
and a copy of the API vendor, public Key stored in the API implementation to 
the CHECK process 922. CHECK process 922 U ses a digital signature 
authentication ("DSA") process to verify the authenticity of the 
LicenseAgreementString. 

The DSA process used by CHECK process 922 can be any digi.M 



■-arpor; :,.!;- , - , ;c nun> digi;_l „, , ire of fhe ^ sHn& p ^ 1 , 

appropriate authentication process, and determining the va.idity of the input 
string by testing whether the key constitutes the signatory* digital signature of 
the mput string. An exemplary DSA process is disclosed, for example, in U S 
Patent Application Serial No. 08/484,264, "Method and Apparatus for Digital 
20 Sl gnature Authentication," assigned to the assignee hereof. The DSA 
technology of RSA Data Security, Inc. also can be adapted for use with the 
invention. A per-session cache can be used to improve execution speed of the 
CHECK process. 



25 



If the LicenseKeyString is determined to be the API vendor's valid 
digital signature of the LicenseAgreementString, the LicenseAgreementString 
» mspected to determine whether it indicates that a site license has beer. 
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granted. If the LieenseAgreementString does so indicate, the 1 test of step 1006 
succeeds and control is passed to step 1014. At this point the UNLOCK 
function returns a positive result to the calling entity, and allows the calling 
entity to use the API. 

If the test of step 1006 fails, control is passed to step 1008 where the 
UNLOCK function extracts and reads the LicenseKeyString and 
LieenseAgreementString from a data segment (for example, the compiled 
constant declarations area) of the calling entity. Alternatively, the calling 
entity may transmit the LicenseKeyString and the LieenseAgreementString to 
the API. Having obtained the calling entity's LicenseKeyString and 
LieenseAgreementString, control is passed to step 1010 where the function 
tests whether the calling entity is licensed to use the API. This test comprises 
two p.'Hs. One part using CHFC K process 922 a.s described abc-ve, determines 
vhether the LieenseAgree mentString is a LieenseAgreementString validly 
issued by the API vendor. A second part examines the 

LieenseAgreementString for the terms of the included license, and determines 
whether those terms are met. If the result is positive then control is passed to 
step 1014. At this point, use of the API with the calling entity is authorized 
and the API returns control to the calling entity so that the calling entity 
resumes normal execution. 

If the result is negative then the calling entity is not licensed to use the 
API, and control is passed to step 1012. At step 1012 the API generates an error 
message such as "API Not Licensed For Use With This Application program," 
and declines access to the calling entity. 
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Steps 1006 and 1010 carry out the license tests by calling the CHECK 
LICENSE function 921 shown in Figure 9 and Figure 11. Processing steps of 
the CHECK LICENSE function 921 are illustrated in Figure 11. 

5 The process flow of the CHECK LICENSE function starts at step 1102. 

Control is passed to step 1104 where the CHECK LICENSE function assembles 
the LicenseKeyString 902, LicenseAgreementString 904, and a copy of the API 
vendor's public key 1106 as function call arguments, in preparation for calling 
the CHECK function 922. As discussed more fully below, the public key 1106 is 
10 prepared by the API vendor based upon a secret private key. The three 
arguments are passed to the CHECK function at step 1108. 

If the CireCK function (d«rril*d ., gre.-ne,- &ta „ b , Io ,,„ „ ^ 

' - ■■ J . C. :IC L ; ;".'-,NS. ■ , n , ;. . 

15 itself reruns a f,, ,- 3te . If „.. , C functior , . LUms . pAsg Qr ^ ^ 

control is passed to step 1112 where the CHECK LICENSE function checks the 
terms of the license specified in the LicenseAgreementString. At step 1114, the 
CHECK LICENSE function checks whether the name of the calling entity is the 
same as the name of the licensed entity specified in the 
20 LicenseAgreementString. If the name of the calling entity is incorrect, control 
passes to step 1124, where a fail message is passed to the UNLOCK function. 

If the name of the calling entity is correct, the CHECK LICENSE 
function tests whether the LicenseAgreementString contains an expiration 
25 date at step 1116. An expiration date can be placed in the 

LicenseAgreementString by the API vendor to establish a termination date 
after which use of the API by the calling entity is no longer allowed. CHECK 
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LICENSE may, for example, test for an expiration date by searching for a text 
string that indicates an expiration date, such as, for example, "expiration date" 
or "valid until." 

> If the test of step 1116 is positive, control is passed to step 1118 where the 

CHECK LICENSE function tests whether the current date, as maintained, for 
example by a computer clock or operating system, is greater than the 
expiration date found in the LicenseAgreementString. If the test of step 1118 
passes, control is passed to step 1120. If the test of step 1118 fails, then CHECK 
LICENSE returns a FAIL message at block 1124. 

At step 1120, the CHECK LICENSE function checks whether the 
LicenseAgreementString specifies any additional license terms. Tf there are no 
other terms, CHECK LICENSE nu-urns « PASS messa,- bicck 13 2C. Tf tiicre 
are other ;,,ns, CHECK LICENSE determines whether those terms are met at 
block 1122. If any of the other terms are not met, CHECK LICENSE returns a 
FAIL message at block 1124. If all of the additional terms are met, CHECK 
LICENSE returns a PASS message at block 1126. 



20 



The operation of the CHECK function called by CHECK LICENSE at 
block 1108 is illustrated in Figure 12. As shown in Figure 12, the purpose of 
the CHECK function is to verify the authenticity of a license agreement string 
by verifying that a corresponding license key string constitutes a valid digital 
signature of the license agreement string. The CHECK function begins at step 
25 1202 and receives as input a LicenseKeyString, a LicenseAgreementString, and 
a vendor's public key in step 1203. The public key is generated by the resource 
library vendor using any known public /private key pair generation process, as 
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is well known in the field of cryptography. For example, key generation using 
Fast Elliptical Encryption (FEE) can be done, or Diffie-Hellman key generation 
can be used. 

5 In step 1204 the CHECK function verifies that the LicenseKeyString 

comprises the digital signature of the LicenseAgreementString. In step 1208, 
the CHECK function tests whether the verification of step 1204 successfully 
verified the LicenseKeyString as comprising the digital signature of the 
LicenseAgreementString. If so, the LicenseAgreementString is valid, and 
10 CHECK returns a Boolean true or pass value. If not, the 

LicenseAgreementString is invalid, and CHECK returns false or failure. 

Since the LicenseKeyString of the present embodiment comprises *be 
.-7T. ( . ;-;!.] ';yr- -Trttij." r.'t the* .• ■ -'-Aj^r* -•. ">; ■ '■ . Lie- - -;t;A •«- '^Sirm 0 ' 

15 cannot be changed in any way without t.'-c cl.cinge being defected. .': -u •: more 
generally, because the identifier (e.g. the LicenseKeyString) of the invention is 
a unique key mathematically derived from a particular text string that 
specifies license terms for a particular end user program (e.g. the 
LicenseAgreementString), the identifier can be used to detect any changes to 

20 the license terms. This prevents unauthorized modification of the text string 
from extending use of a resource library to an unlicensed program. For 
example, if an end user attempts to modify the expiration date using a 
debugger or machine language editor, the identifier will no longer match the 
license text string. Without knowing the private key of the vendor, the end 

25 user cannot generate a matching identifier. 
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When a 127-bit private key's is used by the vendor to' create the 
identifier used in the present invention, a determined hacker attempting to 
forge the private key would need to exhaustively search the 127-bit space, 
requiring extensive computing resources and an impractical amount of time. 
5 Thus, the protection provided by the present invention cannot easily be 
cracked and the security of the invention as a whole is extremely high. 

In addition to allowing per program resource library licensing, if the 
API vendor or licensor desires to grant a site license for the API to the end 
10 user, so that the API is licensed for use with any number of application 
programs, the API may be provided with a LicenseKeyString and a 
LicenseAgreementString providing for such unrestricted use. In this 
embodiment, the API vendor provides a site license key string to the end -user 
as amhoriz-ion to use th* API ,vilh any number of applications and other 
end user programs at that site. The site license key string comprises a digital 
signature of a site license agreement string created by the API vendor. The site 
license agreement string may be pre-embedded in the API by the vendor. 
During installation of the API, an installation program provided with the API 
asks the end user whether a site license key is known. If so, the end user 
enters the site license key, and the installation program writes the site license 
key to a reserved location in the API. Thereafter, when the API initializes, the 
API tests for the presence of the site license key. If it is present, and it 
comprises a valid digital signature for the site license text string stored 
elsewhere in the API, the API is permitted to be used with any application 
program which is calling it. 
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OpenStep API 

In one embodiment of the invention, the API used is the object- 
oriented OpenStep API 820 shown in Figure 8. A specification of the 
OpenStep API has been published by NeXT Software, Inc. under the title 
"OPENSTEP SPECIFICATION;' dated October 18, 1994. Implementations of 
the OpenStep API include implementations for the Windows NT and Solaris 
operating systems that are available from NeXT Software, Inc. and SunSoft, 
Inc., respectively. 

As shown in Figure 8, the OpenStep API 820 comprises computer 
program code organized as an Application Kit 802, Foundation Kit 808, and 

Display Postscript™ system 804. (Display Postscript™ is a trademark of Adobe 

.'.'<;/ -'~v-!S _ >! po.-<ied.) 

Application Kit 802 provides basic resources for interactive application 
programs that use windows, draw on the screen, and respond to user actions 
on the keyboard and mouse. Application Kit 802 contains components that 
define the user interface. These components include classes, protocols, C 
language functions, constants and data types that are designed to be used by 
virtually every application running under the OpenStep API. A principal 
purpose of Application Kit 802 is to provide a framework for implementing a 
graphical, event-driven application. 

Foundation Kit 808 provides fundamental software functions or 
building blocks that application programs use to manage data and resources. 
Foundation Kit 808 defines basic utility classes and facilities for handling 



WO 99/05600 



31 



PCT/US98/15340 



multi-byte character sets, object persistency and distribution, and provides an 
interface to common operating system facilities. Foundation Kit 808 thus 
provides a level of operating system independence, enhancing the developer's 
ability to port an application program from one operating system to another. 

5 

Display Postscript system 804 provides a device-independent imaging 
model for displaying documents on a computer screen. Display Postscript is 
defined by Adobe Systems Incorporated. Display Postscript system 804 
provides an application-independent interface to Postscript. 

10 

Separate from the API 820, but also logically located between the 
application program 800 and the operating system 810, is a set of device 

• dependent windowing extensions 806. Extensions 806 enable Display 
Postscript system 804 !c commur.Ai.-.te with .;peci/k graphics and display 
15 hardware in the end user's computer system, such as the video memory or 
other video display hardware. 

Figure 13 illustrates an embodiment of the invention used with the 
OpenStep API of Figure 8. As shown in Figure 13, in this embodiment, the 

20 license text string and the license key string of the invention are implemented 
in a property list area 1302 (Info.plist) of the application program code 800. 
Two string properties are added to the property list area 1302: 
NSLicenseAgreement 1304, that stores the software license terms applicable to 
application program 800, and NSLicenseKey 1306, that stores the license key 

25 corresponding to NSLicenseAgreement 1304. In this embodiment, as in the 
embodiment of Figure 9, NSLicenseKey 1306 is derived from the 
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NSLicenseAgreement string 1304 generated from the license agreement string 
using a digital signature process and a vendor's private key. 



Example values of the two strings placed in the Info.plist are shown in 
5 Table 2. 

Table 2 - Info.plist Strings 

NSLicenseKey = "Ab76LY2GbbO0GqK2KY17BqHy35" ; 



NSLicenseAgreement = "(c) Copyright 1996, EOF AddOnTools 
10 Inc., ReportWriter licensing agreement: This is 

demonstration software valid until November 2, 1996. 
This software cannot be legally copied. " ; 



In the OpenStep embodiment of Figure 13, the UNLOCK function 1308 

15 is implemented as part of Application Kit 802. In one embodiment, UNLOCK 
f.-.—HciL • 'n 'ft .. Imp", - 'riled vy an.-"^ -op, ?;«•*:« ce-^" 'o a > >o.Vi'^<- ; -i^nsnl" 
y -1c Application Kit function (such a-., e;;a. .!..•• ■, . 'AppZo* - ~ ' • 
NSApplication.m). An example of source code that may be added is shown in 
Table 3. 

20 

Table 3 - UNLOCK Code added in Ope nStep API Implementation 

static BOOL licenseChecked = NO; 
if ( ! licenseChecked) 
25 { 

NSDictionary *info; 

NSString *key, * agreement; 

/* First check the unlimited (per-site) license */ 
info = [NSDictionary 
30 die tionaryWithContentsOf File : @ " /OpenStep/AppKit . dll/Inf o 

.plist"]; // real path TBD 

key = [info objectForKey: ©"NSLicenseKey" ] ; 
agreement = [ info 
obj ectForKey : @ "NSLicenseAgreement " ] ; 
35 if ( INSCheckLicense (key, agreement)) 

{ 

/* now check for the per-app license */ 

info = [ [NSBundle mainBundle] inf oDictionary] ; 
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key = [info objectForKey : @ "NSLd-censeKey " ] ; 
agreement = [info 
objectForKey : @ "NSLicenseAgreement " ] ; 

if (! NSCheckLicense (key, agreement)) 

NSLog (©"*** Sorry no valid license for 
%@", [NSApp appName] ) ; 

} 

} 

licenseChecked = YES; 
} 

The NSCheckLicense() function, which is called twice in the code 
segment of Table 3, as shown in Figure 13, is implemented in the Foundation 
Kit portion 808 of the OpenStep API 820. The NSCheckLicense function 1310 
corresponds to the CHECK LICENSE function 921 illustrated in Figure 9. The 
NSCheckLicense function 1310 verifies NSLicenseAgreement string 1304 
using NSLicenseKey string 1306 and a digital signature authentication process. 
The NSCheckLicense funCrnm 1310 has :he following cicfmitic-v 

extern BOOL NSCheckLicense (NSString *licenseKey, 
NSString *licenseAgreement ) ; 

The NSCheckLicense function 1310, like the Check License function 921 of 
Figure 9, applies a CHECK function 1312 to NSLicenseAgreement string 1304 
and NSLicenseKey 1306, using the API vendor's public key, to determine the 
validity of NSLicenseAgreement string 1304. In the embodiment of Figure 13, 
CHECK function 1312 includes in its code a copy of the API vendor's public 
key 1314. 

In the embodiment of Figure 13, API 820 includes a "GEN" process 1316 
that can be used by an API vendor to rapidly generate license key strings for 
use by CHECK function 1312. GEN process 1316 receives as input a license 
agreement string and a secret private key, and produces as output a licensing 
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key string, using a digital signature generating process. The private key may, 
for example, be a 127-bit private key, although any other size private key may 
be used. The signature generating process used by GEN process 1316 is 
compatible with the digital signature authentication process used by CHECK 
5 function 1312. GEN process 1316 itself can be made entirely public and 

implemented in the API provided that the private key of the API vendor is 
maintained in secrecy. For example, the GEN process can be part of the 
OpenStep API Foundation Kit 808 as shown in Figure 13. GEN also can be 
maintained in a separate program module. 

10 

The logical relationship between GEN and CHECK is: 

CHECK(GEN(LicenseAgreementString, PrivateKey), Public Key, 

LicenseAgreementStrinfr) => YES 

O ^C'^v'i'adOiul, r.uu'.^.-yx'y.) „ r.; with • -■ ;. /. .,>.• '..-biil-y 

In one embodiment of the invention, a shell is provided for the GEN 
process. The shell can receive as input a license agreement template string, 
20 such as: 

(c) Copyright 1995, %@, %@ licensing agreement; Demo 
software valid until %@ ; This agreement cannot be 
legally copied 

25 

where %@ represents additional data to be provided by the API vendor. The 
shell then asks the user (i.e. the API vendor) to input the additional data, for 
example a company name, a product name, an expiration date, from which 
the shell generates a specific license agreement string. The shell then asks for 
30 the private key and applies GEN to create a corresponding license key. 
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The same shell can be used for per-program license keys or per-site 
license keys, using different templates. 

In one embodiment of the invention, an installer program is provided 
5 for installing a resource library on an end user computer. The installer 
program is provided with a feature enabling the end user to provide a site 
license key during installation. For example, if the resource library is the 
OpenStep API, additional code is added to the OpenStep API installer 
program. The user is asked during the installation of the resource library if 

10 the user has obtained a per-site license. If the user replies yes, the user is asked 
to enter the site license key string. In one embodiment, the user is also asked 
to enter the site license agreement string. In another embodiment, the site 
license agreement string is stored in the resource library, such as, for example, 
in the OpenStep API DLL Application Kit's Lifo.pll-i resource file. Th» site 

15 license key. and site license agreement are validated by the CHECK LICENSE 
function as described above. Use of the resource library is permitted only if 
the site license key string input by the user corresponds to (i.e. is found to 
comprise the resource library vendor's digital signature of) the site license 
agreement string. 

20 

Java 

The present invention may be used with resource libraries such as Java 
class files, Java applets, and Java bytecode packages. Figure 14 illustrates an 
25 embodiment of the invention in which the resource library is a Java applet. 
In the embodiment shown in Figure 14, an applet is called from an HTML 
page 1402 via applet tag 1404. Applet tag 1404 includes the name of the 
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10 



applet's class file and applet parameters 1406. Applet parameters 1406 include 
a license agreement string parameter 1408 and a license key string parameter 
1410. License agreement string parameter 1408 specifies a license agreement 
string that contains terms of a license to use the called for applet. License key 
string parameter 1410 specifies a license key used to authenticate the license 
agreement string. As in other embodiments of the invention, in this 
embodiment, the license key string comprises a digital signature by the 
resource library (applet) vendor of the license agreement string. Table 4 
illustrates an example of applet tag 1404. 

Table 4 

< APPLET CODE= "Applet .class" WIDTH=250 HEIGHT=75> 
<PARAM NAME=LicenseAgreementString VAl.UE="Web page 

orderform.html licensed to use applet. ' App3 et . class ' > 

<p;m<am Niv;ii<J-L*- ^aseXevStr.iug V/vu je~ " ■IkdOD- 1 xuk^-r'> 

In the example of Table 4, the license agreement string specifies the 
name of the HTML page ("orderform.html") and the name of the licensed 
applet ("applet.class"). 

As shown in Figure 14, applet 1434 is accessed when HTML page 1402 is 
loaded by a HTML browser 1430 running in a client computer 1420. In the 
embodiment of Figure 14, HTML browser 1430 runs on top of an API 1424 
which in turn runs on top of operating system 1422. HTML browser 1430 
includes a Java virtual machine 1432 for running Java applets. 



Upon encountering applet tag 1404 while loading HTML page 1402, 
30 HTML browser 1430 retrieves the class files that constitute applet 1434 from 
storage locations on client computer 1420 and/or from one or more server 
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computers, as applicable. One of the class files includes CheckLicense class file 
1436. After HTML browser 1430 has retrieved all the required components of 
applet 1434, applet 1434 is initialized. During initialization, or at a later time, 
the CheckLicense function provided by CheckLicense class file 1436 is called. 
5 As in other embodiments of the invention, the CheckLicense function 

determines whether the requesting entity (HTML page 1402) possesses a valid 
license to use the requested resource (applet 1434) by testing the authenticity of 
the license specified by LicenseAgreementString parameter 1408 using the 
license key specified by LicenseKeyString parameter 1410 and the applet 
10 vendor's public key 1438. If the CheckLicense function determines that HTML 
page 1402 possesses a valid license, applet 1434 is allowed to execute. If not, 
execution of applet 1434 is terminated, and an error message is sent to HTML 
browser 1430. 

15 Thus, ?n improved method and apparatus for «, faring software 

licenses has been presented. Although the present invention has been 
described with respect to certain example embodiments, it will be apparent to 
those skilled in the art that the present invention is not limited to these 
specific embodiments. For example, although the invention has been 

20 described for use in stand-alone computer systems, the invention can be used 
to enforce licenses in a network environment as well. Further, although the 
operation of certain embodiments has been described in detail using specific 
software programs and certain detailed process steps, different software may be 
used, and some of the steps may be omitted or other similar steps may be 

25 substituted, without departing from the scope of the invention. Other 

embodiments incorporating the inventive features of the present invention 
will be apparent to those skilled in the art. 
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CLAIMS 

1. In a computer operating environment comprising a software 
5 program and a software resource, an apparatus for limiting use of said 
software resource comprising: 

an access authorization indicator associated with said software program; 

means in said software resource for reading said access authorization 
indicator; 

10 means in said software resource for determining whether said access 

authorization indicator is valid; 

means for allowing access by said software program to said software 

resource only if said access authorization indicator is determined to be valid. 

:5 2. 'l'he apparatus of claim 1 wherein said access a>. orization 

indicator comprises terms of a license for use of said software resource. 

3. The apparatus of claim 1 wherein said access authorization 
indicator comprises terms of a site license. 

20 

4. The apparatus of claim 1 wherein said access authorization 

indicator is embedded in said software program. 

5. The apparatus of claim 1 wherein said software resource 
25 comprises an API. 
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6. The apparatus of claim 1 wherein said software resource 
comprises a runtime library. 

7. The apparatus of claim 1 wherein said software resource 
5 comprises a dynamic link library. 

8. The apparatus of claim 1 wherein said software resource 
comprises an applet. 

10 9. The apparatus of claim 1 wherein said software resource 

comprises a bytecode package. 

10. The apparatus of claim 1 wherein said software resource 

compiles an OL£ enabled application program. 

15 

11. The apparatus of claim 4 wherein said access authorization 
indicator is specified in a constant declaration area of said software program. 

12. The apparatus of claim 4 wherein said access authorization 
20 indicator comprises a property of a property list of said software program. 

13. The apparatus of claim 1 further comprising an identifier 
associated with said access authorization indicator and wherein said means for 
determining the validity of said access authorization indicator comprises 

25 means for determining whether said access authorization indicator is valid 
based on said identifier. 
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14. The apparatus of claim 13 further comprising means for 
receiving said identifier from an end user. 

15. The apparatus of claim 14 further comprising means for storing 
5 said identifier in said software resource. 

16. The apparatus of claim 13 wherein said identifier is embedded in 
said software program. 

10 17. The apparatus of claim 13 wherein said identifier comprises a 

digital signature of said access authorization indicator. 

18. The apparatus of claim 16 wherein said identifier is specified in a 

■-',-aru ■' -Hr.-r -^-icn 3* en of .::.*. id rtovl/ - «ve ;ut;}*ra>.r.. 

15 

19. The apparatus of claim 16 wherein said identifier comprises a 
property of a property list of said software program. 

20. The apparatus of claim 17 wherein said means for determining 
20 whether said access authorization indicator is valid based upon said identifier 

comprises a means for digital signature authentication. 

21. The apparatus of claim 2 further comprising means for 
determining whether said terms of said license are met. 
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22. The apparatus of claim 13 wherein: , 

said software program comprises said access authorization indicator and 
said identifier; 

said access authorization indicator comprises terms of a license for use 
5 of said software resource; 

said identifier comprises a digital signature of said access authorization 
indicator. 

23. In a computer operating environment, a method for limiting use 
10 of a software resource comprising: 

receiving a request from a software program to use said resource; 

obtaining an access authorization indicator associated with said 
software program; 

determining wnelhcr said access authorization indicator 5s valid; 
15 allowing said software program to use said software resource only if 

said access authorization indicator is determined to be valid. 

24. The method of claim 23 wherein said access authorization 
indicator comprises terms of a license for use of said software resource. 

20 

25. The method of claim 24 wherein said license comprises a site 
license. 



26. The method of claim 23 wherein said access authorization 
25 indicator is embedded in said software program. 
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27. The method of claim 23 wherein said software resource 
comprises an API. 

28. The method of claim 23 wherein said software resource 
5 comprises a runtime library. 

29. The method of claim 23 wherein said software resource 
comprises a dynamic link library. 

10 30. The method of claim 23 wherein said software resource 

comprises an applet. 

31. The method of claim 23 wherein said software resource 

15 

32. The method of claim 15 wherein said software resource 
comprises an OLE enabled application program. 

33. The method of claim 26 wherein said access authorization 

20 indicator is specified in a constant declaration area of said software program. 

34. The method of claim 26 wherein said access authorization 
indicator comprises a property of a property list area of said software program. 
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35. The method of claim 23 wherein said determining the validity of 
said access authorization indicator comprises determining whether said access 
authorization indicator is valid based on an identifier associated with said 
access authorization indicator. 

5 

36. The method of claim 35 further comprising accepting said 
identifier from a user. 

37. The method of claim 36 further comprising storing said identifier 
10 in said software resource. 

38. The method of claim 35 wherein said identifier is embedded in 

said software program. 

15 . 39. The method of claim 35 wherein said identifier comprises a 

digital signature of said access authorization indicator. 

40. The method of claim 38 wherein said identifier is specified in a 
constant declaration area of said software program. 

20 

41. The method of claim 38 wherein said identifier comprises a 
property of a property list area of said software program. 

42. The method of claim 35 wherein a digital signature 
25 authentication means is used in determining whether said access 

authorization indicator is valid based upon said identifier. 
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43. The method of claim 24 further comprising determining 
whether said terms of said license are met. 

44. The method of claim 35 wherein: 

5 said software program comprises said access authorization indicator and 

said identifier; 

said access authorization indicator comprises terms of a license for use 
of said software resource; 

said identifier comprises a digital signature of said access authorization 
10 indicator. 

45. A program storage device readable by a machine, tangibly 
embodying a program of instructions executable by the machine to perform a 

^rho<: r u- 'ing u.,,: of a s^U— -re rc?oi • cc. cz'-i r-rJ.'v.iH eo •": 
- receiving a r^iu^i from a solLvare program vo use :,.;.>■:. ;.^urce; 

obtaining an access authorization indicator associated uuh. said 
software program; 

determining whether said access authorization indicator is valid; 
allowing said software program to use said software resource only if 
20 said access authorization indicator is determined to be valid. 

46. The program storage device of claim 45 wherein said access 
authorization indicator comprises terms of a license for use of said software 
resource. 

25 

47. Thfe program storage device of claim 46 wherein said license 
comprises a site license. 
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48. The program storage device of claim. 45 wherein said access 
authorization indicator is embedded in said software program. 

49. The program storage device of claim 45 wherein said software 
resource comprises an API. 

50. The program storage device of claim 45 wherein said software 
resource comprises a runtime library. 

51. The program storage device of claim 45 wherein said software 
resource comprises a dynamic link library. 

52. The program storage device of :Iaim 45 wherein said software- 
resource comprises an applet. 

53. The program storage device of claim 45 wherein said' software 
resource comprises a bytecode package. 

54. The program storage device of claim 45 wherein said software 
resource comprises an OLE enabled application program. 



55. The method of claim 48 wherein said access authorization 
indicator is specified in a constant declaration area of said software program. 
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56. The program storage device of claim 48 wherein said access 
authorization indicator comprises a property of a property list area of said 
software program. 

5 57. The program storage device of claim 45 wherein said 

determining the validity of said access authorization indicator comprises 
determining whether said access authorization indicator is valid based on an 
identifier associated with said access authorization indicator. 

10 58. The program storage device of claim 57 wherein said method 

further comprises accepting said identifier from a user. 

59. The program storage device of claim 58 wherein said method 

f'.Triher co. ••prises otorJ.vj bnid : :' jiiii:'-.-? in >? : -l si.lt-vMre r~r.cn.- - 

15 

60. The program storage device of claim 57 wherein said identifier is 
embedded in said software program. 

61. The program storage device of claim 57 wherein said identifier 
20 comprises a digital signature of said access authorization indicator. 

62. The program storage device of claim 60 wherein said identifier is 
specified in a constant declaration area of said software program. 

25 63. The program storage device of claim 60 wherein said identifier 

comprises a property of a property list area of said software program. 
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64. The program storage device of claim 57 wherein a digital 
signature authentication means is used in determining whether said access 
authorization indicator is valid based upon said identifier. 

5 65. The program storage device of claim 46 in which said method 

further comprises determining whether said terms of said license are met. 

66. The program storage device of claim 57 wherein: 

said software program comprises said access authorization indicator and 
10 said identifier; 

said access authorization indicator comprises terms of a license for use 
of said software resource; 

said identifier comprises a digital signature of said access authorization 
indicator. 

15 

67. An article of manufacture comprising: 

a computer readable medium having computer readable program code 
embodied therein for accessing a resource library, said computer readable 
program code in said article of manufacture comprising: 
20 computer readable program code embodying an access authorization 

indicator for accessing said resource library. 



68. The article of manufacture of claim 67 wherein said access 
authorization indicator comprises terms of a license for use of said software 
resource. 
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69. The article of manufacture of claim 67 wherein said computer 
readable program code comprises a software program and wherein said access 
authorization indicator is embedded in said software program. 

5 70. The article of manufacture of claim 67 wherein said software 

resource comprises an API. 

71. The article of manufacture of claim 67 wherein said software 
resource comprises a runtime library. 

10 

72. The article of manufacture of claim 67 wherein said software 
resource comprises a dynamic link library. 

'/3. Vh« autcle <-f manufacture of r«-:v--\ ,'<7 w hcr: >l .-airi -'.■•.-'tw;;> ; 
15 resource comprises an applet. 

74. The article of manufacture of claim 67 wherein said software 
resource comprises a bytecode package. 

20 75. The article of manufacture of claim 67 wherein said software 

resource comprises an OLE enabled application program. 

76. The article of manufacture of claim 69 wherein said access 
authorization indicator is specified in a constant declaration area of said 
25 software program. 



BNSDOCID: <WO 99O560OA2J_> 



WO 99/05600 



49 



PCT/US98/1S340 



77. The article of manufacture of claim 69 wherein said access 
authorization indicator comprises a property of a property list of said software 
program. 

78. The article of manufacture of claim 67 further comprising 
computer readable program code embodying an identifier associated with said 
access authorization indicator. 

79. The article of manufacture of claim 78 wherein said identifier is 
embedded in said software program. 

80. The article of manufacture of claim 78 wherein said identifier 
comprises a digital signature of said access authorization indicator. 

81. The artic-u oii manufacture of claim 78 wherein said identifier is 
specified in a constant declaration area of said software program. 

82. The article of manufacture of claim 78 wherein said identifier 
comprises a property of a property list of said software program. 

83. The article of manufacture of claim 78 wherein: 

said software program comprises said access authorization indicator and 
said identifier; 

said access authorization indicator comprises terms of a license for use 
of said software resource; 

said identifier comprises a digital signature of said access authorization 
indicator. 
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